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FOREWORD 


This  paper  will  describe  a  combat  system  integration  and  designed  analysis 
tool  called  the  Ship  Combat  System  Simulation  (SCSS).  This  work  was  funded  under 
the  Combat  System  Architecture  (CSA)  Project.  The  SCSS  was  desigend  as  an 
analysis  tool  to  study  sensor,  command  and  control,  and  weapon  system  integration 
for  shipboard  combat  systems.  The  simulation  represents  the  combat  system 
components  as  nodes  in  a  network.  The  nodes  are  connected  by  links.  Data  flows 
between  the  nodes  through  the  links.  1 

The  SCSS  has  been  jointly  developed  by  NWC,  NOSC,  NSWC,  and  CACI,  Inc.  SCSS 
is  supported  by  naval  and  industrial  laboratories  throughout  the  country.  The 
users  of  the  simulation  belong  to  the  SCSS  Users'  Group,  which  meets 
periodically.  Members  of  the  Users'  Group  develop  equipment  nodes  and  exchange 
ideas.  The  Users'  Group  maintains  SCSS  configuration  management  allowing  for 
Simscript  II. 5  code  written  by  any  one  user  to  be  used  by  all  other  users.  NSWC 
has  been  tasked  to  handle  part  of  the  configuration  management  of  the  model. 

This  task  involves  answering  inquiries  about  the  model  from  potential  users. 

This  document  will  be  distributed  as  part  of  that  task. 

Approved  by : 

>•'(//’  .  i  t  (*•/(.- 

PAUL  R.  WESSEL,  Head 

Combat  Systems  Department 
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INTRODUCTION 


In  recent  years  the  U.S.  Navy  has  found  itself  faced  with  a  severe, 
multi-threat  environment.  Probably  the  most  important  component  of  this  threat 
is  the  cruise  missile  which  may  be  launched  from  a  variety  of  platforms.  In 
response  to  this  threat  the  Navy  has  developed  several  new  sensor  and  weapon 
systems.  As  these  new  systems  are  introduced  into  the  fleet,  it  has  become  clear 
that  there  is  a  pressing  need  to  integrate  them  together  in  such  a  way  that 
information  from  multiple  sensors  can  be  organized  and  properly  used  almost 
instantaneously.  This  integration  problem  has  led  to  the  development  of  a  new 
analysis  tool,  the  Ship  Combat  System  Simulation.  Previous  simulations  of 
shipboard  systems  have  stressed  sensor  and  weapon  problems,  usually  modeling 
command  and  control  as  a  time  delay.  This  weapon-sensor  approach  to  combat 
system  simulation  gave  models  a  structure  which  proved  to  be  insufficiently 
flexible  to  handle  the  systems  integration  problem.  SCSS  has  been  developed  with 
a  structure  which  will  overcome  many  of  these  problems. 

The  objective  of  the  SCSS  project  is  to  develop  a  combat  system  simulation 
which  may  be  used  to  analyze:  (1)  the  total  system  impact  of  proposed  design 
changes  in  weapons  and  sensors  and  (2)  the  effectiveness  of  various  methods  of 
weapon  system  integration.  The  ship's  combat  system  is  treated  as  an 
information-flow  network  so  that  individual  components  may  be  studied  in  the 
context  of  information  received,  information  processed  (and  delayed),  and 
information  used.  Misinformation,  as  well  as  correct  information,  is  allowed  to 
enter  and  flow  through  the  network.  Figure  1  presents  a  typical  SCSS  network 
(link/node)  diagram.  The  nodes  shown  represent  elements  of  a  ship  combat  system 
such  as  a  fire  control  radar  or  a  weapons  launcher.  The  nodes  as  linked  together 
make  up  the  combat  system. 

Probably  as  important  as  the  model's  constructs  (such  as  nodes,  links, 
messages,  networks,  etc.)  are  the  model's  structural  forms.  The  secondary 
objective  has  also  been  to  create  a  structure  which  could  be  changed  as  new 
design  concepts  are  introduced.  A  completely  modular  structure  has  been 
developed  which  includes  a  parallel  modular  structure  documentation  package.  The 
documentation  is  maintained  on  the  computer  with  the  model  and  is  updated  right 
along  with  the  code. 

Finally,  it  has  also  been  the  objective  of  this  project  to  provide  a  model 
which  will  be  useful  to  all  Navy  laboratories.  The  model  has  been  a  joint 
development  project  of  the  Naval  Ocean  Systems  Center  (NOSC),  the  Naval  Weapons 
Center  (NWC),  and  the  Naval  Surface  Weapons  Center  (NSWC)  under  funding  from  the 
Naval  Sea  Systems  Command.  The  Naval  Ships  Weapons  Systems  Engineering  Station 
(NSWSES)  has  been  peripherally  involved. 
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SIMULATION  DESCRIPTION 


The  Shipboard  Combat  System  Simulation  (SCSS)  is  written  in  a  process 
orientation  of  Simscript  II. 5.  The  simulation  has  two  distinct  yet  over lapp * n,, 
world  views.  First,  there  is  the  external  world  in  which  all  the  observable 
objects  (processes)  operate.  Each  of  these  observable  objects  can  involve  many 
processes  which  communicate  with  each  other.  The  shipboard  combat  system 
represents  the  internal  view  of  the  observable  object.  In  the  external  world 
interprocess  communication  is  accomplished  by  appropriate  calls  to  a  BOOKKEEPER 
routine;  whereas,  the  shipboard  combat  system  processes  communicate  via  the 
node-link  message  constructs  shown  in  Figure  1. 

The  ship  combat  system  is  represented  in  SCSS  as  a  network  of  information 
processors.  Each  node  in  the  network  represents  a  decision  or  action  unit  in  the 
system.  Figure  2  presents  the  node  description.  Incoming  messages  from  other 
nodes  arrive  at  the  node's  message  handler.  This  portion  of  the  node  decodes  the 
message,  extracts  the  data  from  the  message,  and  routes  the  message  and  data  to 
the  appropriate  function.  The  selected  function  uses  the  incoming  data  together 
with  the  node's  data  (local  data)  and  the  combat  system  data  available  to  the 
node  (global  data)  to  make  a  decision  or  take  some  action.  The  decision  and/or 
action  and  the  corresponding  data  is  formulated  into  a  message  and  sent  out  over 
links  to  the  nodes  in  the  c~'~Ktt  •"/stem.  Th  ,iok  serves  as  an  information 
transfer  path.  Some  links  i  .-resent  compute,  transfer  paths.  Others  .epresent 
voice  phones,  etc. 

Associated  with  each  node  is  a  process  description  of  the  simulated  combat 
system  element.  Examples  of  such  processes  range  from  the  radars  which  interface 
with  the  external  world  (see  below)  to  the  launcher,  the  air  detector/tracker, 
the  ship  weapons  coordinatoi  etc. 


Figure  3  presents  the  i  .e  Control  Comp  . ter,  Fire  Control  Radar,  and 
Launcher  nodes  with  their  process  description.  Each  process  performs  a  function 
shown  in  the  node  description  in  Figure  2.  For  example,  the  fire  control  radar 
performs  the  functions:  slewing  to  a  bearing,  acquiring  a  threat,  preparing 
itself  to  operate,  scanning  to  locate  the  threat,  and  tracking  the  threat.  The 
model  is  intentionally  very  modular  so  that  as  requirements  change,  new  systems 
(nodes  or  combinations  of  nodes)  may  be  quickly  integrated  into  it. 

Most  node-processes  are  message  driven.  An  arriving  message  (presumably 
sent  by  some  other  node)  causes  some  action  to  be  taken  by  the  node.  The 
response  of  a  node  to  a  message  falls  in  one  of  the  following  categories: 

1.  The  message  is  ignored  and  discarded. 


2.  The  message  is  enqueued  (possibly  according  to  some  priority  scheme)  for 
later  processing. 

3.  The  message  is  so  important  that  it  interrupts  the  node-process 
(regardless  of  what  it  is  currently  doing)  so  as  to  process  this  new  message 
immed iate ly . 
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FIGURE  3.  NODE  FUNCTIONS 
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4.  Sometimes  messages  can  be  processed  concurrently .  For  example,  a 
launcher  can  respond  to  a  "warm-up  missile"  command  while  "slewing  to  a  bearing." 

Figure  4  illustrates  the  messages  that  flow  between  the  indicated  nodes  for 
the  functions  assigning  a  threat  track  to  a  specific  weapon  system  and  for 
launching  a  weapon  at  that  threat.  For  both  of  these  functions  the  circled 
numbers  indicate  the  flow  of  the  labeled  messages  through  the  corresponding  links. 

The  names  of  the  combat  system  components  simulated  by  these  nodes  are  also 
shown  in  the  figure.  The  THREAT  RESPONSE  MODULE/TRACK  STORES  nodes  is  a  top 
level  model  of  the  NTDS  computer  systems.  It  should  be  noted  that  these  nodes 
are  generic  in  nature  and  can  be  configured  as  specific  components  through  input 
data . 


The  interface  between  the  ship  combat  system  and  the  external  world  is 
mainly  by  radar.  Since  objects  are  moving  continuously  (incoming  threats, 
friendly  aircraft,  launched  missiles,  etc.),  it  is  necessary  to  keep  track  of 
where  everything  is.  This  is  represented  by  an  instantaneous  "snapshot" 
approach.  For  a  rotating  antenna,  one  snapshot  is  produced  per  revolution.  Then 
appropriate  adjustments  are  made  to  the  computations  so  that  objects  in  the 
external  world  will  "appear"  at  the  correct  time  in  the  correct  place  on  a  radar 
screen  (plan-position-indicator;  PPI).  The  characteristics  of  the  radar  are 
taken  into  consideration,  resulting  in  elimination  of  "blips"  which  represent 
objects  that  are  out  of  radar  range,  hidden  by  another  object,  etc. 

Certain  node-processes  look  at  the  information  presented  on  the  PPI  and 
initiate  messages  based  on  the  situation.  Other  node  processes  work  somewhat 
autonomously,  updating  their  own  files,  etc. 


EXTERNAL  WORLD 


The  environment  in  which  the  ship  is  embedded  includes  missiles  and  threats 
(cruise  missiles)  in  addition  to  the  ship.  The  ship  is  on  a  sea  characterized  by 
sea  state.  The  sea  state  affects  reflectivity  and  sea  roll.  This  ship  has  the 
capability  of  changing  headings  and  speeds.  The  missiles  fly  through  a  three- 
dimensional  environment.  The  missiles  and  threats  fly  pursuit  navigation  when 
command  guided  or  pursuing  a  heading  and  fly  linearized  proportional  navigation 
in  homing  on  a  traget.  All  target  detections  are  based  on  a  curved  earth; 
however,  all  homing  assumes  flat  earth  for  simplicity. 

All  external  processes  must  belong  to  the  common  EXT. ENVIRONMENT. SET  to  be 
observable.  All  interactions  between  external  processes  are  managed  by  a 
BOOKKEEPER  routine.  All  external  processes  have  a  PROGRAMMED. TRAJECTORY 
subprocess  to  handle  preprogrammed  thrust  changes  and  altitude  changes.  Also, 
they  have  a  common  NAVIGATION  subprocess  which  performs  the  trajectory  maneuvers 
through  the  three-dimensional  space.  In  addition,  missiles  and  threats  have  a 
common  SEEKER  subprocess  which  allows  them  to  detect,  lock-up  on,  and  guide  to  a 
target . 
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SCSS  NODE  AND  LINK  DIAGRAM 
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FIGURE  4.  MESSAGE/DATA  FLOW 
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•  CONSTRUCT  A  COMMAND,  CONTROL,  COMMUNICATIONS  DIAGRAM 

•  CONSTRUCT  A  SEQUENCE  AND  TIMING  DIAGRAM 

•  CONSTRUCT  AN  INITIAL  CONDITION  TABLE 
FOR  THE  EXTERNAL  ENVIRONMENT 

•  CONSTRUCT  A  LINK  NODE  DIAGRAM 

•  COLLECT  OATA  FOR  SPECIRC  PROBLEM 

•  INPUT  COLLECTED  OATA 

•  RUN  THE  MODEL 

•  ANALYZE  THE  RESULTS 

FIGURE  5.  PROCEDURE  FOR  USING  SCSS 
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MODEL  CAPABILITY 


Initially  the  simulation  was  intended  for  a  single  ship  combat  system 
analysis.  The  most  current  version  is  a  multiple  ship  model  which  may  be  used 
simulate  NTDS  type  ships  faced  with  a  cruise  missile  attack.  The  modules 
completed  to  date  are  the  following: 

1.  Searcli  radar  and  associated  IFF  equipment 

2.  Air  detector/lracker  (human) 

3.  Automatic  detec  tor /t racker 

4.  Track  supervisor 

5.  NTDS-like  computer  (tracking  module  and  threat  response  module) 

6.  Ship  Weapons  Coordinator  (SWC) 

7.  Fire  Control  Systems  Coordinator  (FCSC) 

8.  Fire  control  computer 

9.  Fire  control  radar 

10.  Launcher 

11.  Fire  control  radar  operator 

12.  Missiles 

13.  Threats  (cruise  missiles) 

14.  Gun  fire  control  computer 

15.  Rapid  f  ire  gun 

16.  Gun  fire  control  computer 

17.  Control  officer  console 

18.  Gun  control  console 

19.  Track  while  scan  radar  (SPQ-9) 

20.  Five  inch  54  gun 

21.  Jamming 

22.  External  Communications 
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23.  Vertical  Launch  System 

The  above  modules  may  be  put  together  in  many  different  combinations  to 
nulate  widely  differing  combat  systems. 


APPLICATION 


A  procedure  tor  using  SCSS  tor  an  antiair  warfare  (AAW)  system  is 
lustrated  in  Figure  5.  The  procedure  for  using  SCSS  implies  an  intimate 
owledge  of  (1)  the  specific  AAW  problem  and  (2)  the  platform's  AAW  combat 
stem  components.  This  knowledge  leads  to  the  construction  of  the  command, 
ntrol,  and  communications  ( C  -^ )  diagram  for  the  AAW  system.  The  C^  diagram 
then  mapped  into  the  SCSS  link/node  as  diagram  shown  in  Figure  6.  Upon 
amination  of  Figure  b  i'  will  be  evident  how  events  are  driven  by  messages 
owing  between  the  nodes. 


SUMMARY 


The  simulation  is  controlled  by  a  Users'  Group.  Any  organization  which  has 
Navy  connection  fsuch  as  a  contract),  Navy  or  private  industry,  can  obtain  the 
mulation  by  becoming  a  member  of  this  Users'  Group.  Additional  information 
garding  the  simulation  or  Users'  Group  membership  can  be  obtained  by  contacting 

D.  R.  Mensh  or  D.  P.  Lynch 
Code  N13 

Naval  Surface  Weapons  Center 
Silver  Spring,  ML)  20910 


Telephone  (202)  394-1237/1247 


NSWC  TR  84-182 


FIGURE  6.  LINK  NODE  DIAGRAM 
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